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ABSTRACT 


A client enabled to load and run Java applets in a distributed 
object computing system retrieves needed Java classes in a 
location-independent manner from various class servers in 
the system. Initially, the client queries a naming service of 
the distributed object computing system to determine the 
class server that contains the base class needed. A connec- 
tion through an object request broker is made from the client 
to the class server. The client then requests the code for the 
base class from the class server by using the object request 
broker. The class server retrieves the code by either reading 
a file from its own local file set, or if the code is not local, 
queries the naming service for another class server that has 
access to the code for the base class. This process of finding 
a class server and determining if the code is local may be 
recursive as classes may be moved or renamed. The class 
server then returns this code to the client by way of the 
object request broker. The client determines whether the 
returned code contains any unresolved classes, i.e., classes 
that are used but not yet defined or loaded. The client 
requests code for any unresolved class in a manner as above 
for the base class. The client incorporates Java software to 
run the applets and ORB binding software to enable the 
software to make calls to the object request broker. A 
network class loader enables the client to load and resolve 
classes over a distributed object system. 

30 Claims, 6 Drawing Sheets 
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USING A DISTRIBUTED OBJECT SYSTEM that are needed but not yet loaded are termed "unresolved", 

TO FIND AND DOWNLOAD JAVA-BASED whereas classes that are needed and that are loaded (or 

APPLICATIONS deBned) are termed "resolved." So, before the use of the 

Web, the classes of a particular applet were stored in a 

FIELD OF THE INVENTION 5 collection of files in a file system of the local computer. The 

„ ... .... Java interpreter running on the local computer would then 

The present invention relates generally to acquiring apph- acC65S the ]ocal file s tem ^ retrieve the ffles ^s^. 

cation program code within a computer system. More k t0 ^ classes it ne6ded Un f ornmatelV) Java woiad men 

specifically, the present invention relates to acquiring Java- onl ta able t0 retrfeve a ]ets avajlable from the , ocal flle 

based apphcauons within a dtstnbuted object system. ^ system only ^ local ffle system fa to the 

BACKGROUND OF THE INVENTION *^ ava m ^ Qr P TQ ^ QT - Also, these classes had to be specified by 

giving a fixed file name. 

With the increasing popularity of the Internet, there has with the advent of browsers available for the Web, 

been a corresponding increase in the demand to be able to however, Java is able to find and download applets from 

transfer and to view information via the Internet, In general, JS re m 0 te sites; however, this acquisition of applets is still 

the Internet is used to communicate with others via elec- limited. In these situations, a browser typically incorporates 

tronic mail and also to view information within an interna- a Java interpreter in order to execute applets that are 

tional network of computers. One aspect of the Internet is downloaded. A Java applet is downloaded by first ideutify- 

the World Wide Web (the "Web"). Among other uses, the ^ the name of me base class desired . Qnce that base class 

Web is used to access Web sites (or Web pages) of a 2Q is identified and loaded, the other classes used by that base 

particular company, organization or person. These Web sites class are tDen retr i eV ed and loaded into the Java interpreter, 

contain information and are available for viewing as part of Because a browser typically uses the hypertext transfer or 

the World Wide Web. When a user accesses a Web site, « nttp » protocol, the location of these Java classes within the 

typically information from that Web site is downloaded to computer network are identified using a Universal Resource 

the user's computer. This information includes graphics, 25 Locator (url) address. A URL address connects machines 

windows, text, photographs, sound, video and other infer- together. It provides a machine name plus a path to a file on 

mation suitable for passing over a computer network. mat ma chine. Thus, through the URL address, the individual 

Typically, software known as a "Web browser" is used to files that contain the Java classes may be identified within a 

browse through the Web to search for particular Web sites computer network. The http server running on the identified 

and information, to connect to a particular Web site, and 30 machine reads these files and then sends the classes (in the 

finally to download the information from that Web site onto form of executable bytes) back to the requesting browser for 

the user's computer. A wide variety of Web browsers are execution. 

available. By way of example, two popular Web browsers An example of how this process works may be illustrated 

are "Netscape" and "Mosaic". When using such a browser to ^ follows. Typically, Web pages are described in a hypertext 

download information from a Web site, the information 35 markup language (HTML) that defines how the Web page 

often appears within a window on the screen of the user's ^1 appear and perform when downloaded to the user's 

computer. And it is then often desirable to also bad execut- computer. In the course of using a Web browser such as 

able program code that may then be executed on the user's Netscape for downloading such a Web page, the user may 

computer within the window or a smaller sub-window. One encounter a Java applet embedded in the HTML that indi- 

technique available for loading and executing program code ^ cates a base class to load. In other words, the HTML page 

on a user's computer uses the Java programming language data that a user may acquire through Netscape contains 

available from Sun Microsystems, Inc., of Mountain View, references to applet classes that may be used to execute 

Calif, small programs in parts of the page. Thus, Netscape would 

Java is a programming language that also includes an be directed to locate and download the code for the applet to 

interpreter as a run-time environment. It is an object- 45 run in the frame that the page defines. This code is found by 

oriented programming language that is designed to support reference to a specific URL address that identifies a particu- 

applications on networks. Java applications that execute lar computer. 

within the run-time environment are known as applets. A The drawback with either defining Java classes as being 

Java applet contains compiled code that is portable and may contained in files available on a local file system or as being 

be executed on any computer running the Java interpreter. 50 contained in files that are accessible through a URL address 

Structurally, each applet is a collection of classes that may ^ that these file names are "hard-wired". In other words, the 

be stored on a computer in a file system. Because Java is a user wao desires an applet must know the actual name of the 

dynamic language these classes may be loaded as they are file that corresponds to a physical machine somewhere. It 

needed from across a network. There may be one class per ma y be difficult to obtain or to update this name. For 

file, or there may be many classes in a given file. Java may 55 example, if the Java applet or any of its classes are moved, 

be running on a single computer or on a number of com- then these file names must be changed. This is an awkward 

puters within a network. And although Java may be used in and undesirable situation in the context of the Internet where 

conjunction with a Web browser, Java may also be used as applets and classes might be located in different locations 

part of any computer system or network. Adescription of the and where it may be desirable to move these classes. For 

Java language may be found in "Java in a Nutshell" by 60 example, an applet might be used in the context of a Web 

David Flanagan, available from O'Reilly & Associates, browser where the applet performs the function of display- 

Sebastopol, Calif., 1996. in g satellite weather information for a particular Web site. In 

Before the popularity of the Web, a Java interpreter loaded the course of displaying the information, the applet may 

applets for execution that were present on the local com- need to find and download various classes within the net- 

puter. In Java, typically a base class desired is loaded first, 65 work. It would be undesirable if one class could not be found 

and this base class indicates further classes that are used by either because its hard-wired file path name had changed or 

the base class and thus need to be loaded as well. Classes if the class name had changed. Such a situation might result 
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in the weather display halting while only halfway done. this determination process in a recursive manner until the 

Also, if the particular computer is down, the needed classes desired portion of applet execution code is found, 

are inaccessible even if those classes are available elsewhere j D another aspect, once the portion of applet execution 

in the network. coc je is returned to the client, the client determines whether 

Especially within a distributed object system, the current 5 the portion of code contains any unresolved references to 

model for finding and downloading Java classes according any other portion of the applet execution code. These 

to "hard-wired" file names breaks down. For example, the unresolved references may take the form of classes used by 

beauty of a distributed object system is that references may loaded execution code that are not yet defined or loaded. If 

be made to objects (such as classes or files) without needing there are unresolved references, the client requests addi- 

to know where exactly those objects are located. Also, a 10 tional applet execution code corresponding to these unre- 

proper distributed object system allows those objects to be solved references from the first applet server found. In turn, 

located anywhere within the system yet still allow a request- this applet server either returns the code itself, or queries the 

ing entity to find the objects that it needs. Thus, current naming service for another applet server with access to the 

schemes for finding and downloading Java classes according code. Id this fashion, all applet execution code needed is 

to a "hard-wired*' file name are not suitable within a dis- 15 loaded into the client for execution, 
tributed object system. Accordingly, it would be desirable to 

have a technique for finding and downloading Java-based BRIEF DESCRIPTION OF THE DRAWINGS 

applications within a distributed object system. Such a ^ mventioil) t ther ^ advantages thereofj 

technique would allow a requesting entity to query one may best be by reference t0 the foUowing 

source for an applet yet be able to find and download all 20 descriptioa takeQ m conjuactioa ^ me accompanying 

classes needed by that applet no matter where they exist drawings in which: 

within the distributed object system and without having to . .„ A ' . . « 

give an exact host machine and file name for these classes. J lG - U lUus ' ra, f \^ uted .<*J«« .ysUoi having an 

° object request broker (ORB) portion, object development 

SUMMARY OF THE INVENTION 25 facilities and client and server objects according to one 

embodiment of the present invention. 

Embodiments of the present invention relate to apparatus FIG. lb shows the flow of a request from a cheat to a 

and methods used to acquire applet execution code within a servant object within the distributed object system of FIG. 

distributed object computing system. The distributed object ^ a 

computing system includes clients, applet servers and an , n ™„ + . ... t . . r ... 

i_._i .i_i j . _ *i*i _ - .- 30 riu. 1c is an embodiment or an obied reference suitable 

object request broker arranged to facilitate communication r .... . ., . . . J , frt „„ - _ 

. ; v . j _u i . . .v j for tise within the distributed object system of FIGS, la and 

between the clients and the applet servers. In a method ^ J J 

aspect, initially a client queries the object request broker to 

determine if there is an applet server available within the FIG - 2 shows a Java client ob J ect rec l uesl broker 

system that may be used to obtain particular applet execu- 3 , m order to download Java class files from various class 

lion code. In another step, the client requests a portion of this servers according to one embodiment of the present lnven- 

applet execution code from a found applet server by using tl0n * 

the object request broker. Once requested, the applet server FIG. 3 shows in greater detail the Java client of FIG. 2 

retrieves a portion of the desired applet execution code. The including modules that it uses to download Java classes 

applet server is then able to return this portion of applet 40 according to one embodiment of the present invention, 

execution code to the client by way of the object request FIG. 4 is a flow chart for acquiring Java classes within a 

broker. distributed object system according to one embodiment of 

In a related aspect, the client incorporates applet software the present invention, 

to enable the client to run the applet execution code. The FIG. 5 is a flow chart showing the request code step of 

client may also have loaded specialized ORB binding soft- 45 FIG. 4 in greater detail according to one embodiment of the 

ware to enable the applet software to make calls to the object present invention. 

request broker, and may have a network class loader to FIG. 6 shows a typical computer system suitable for 

enable the client to load portions of the applet code and to implementing the present invention, 
resolve portions of the code. The applet software may be a 

version of the Java programming language and run-time 50 DETAILED DESCRIPTION OF THE 

environment that allows the client to run Java applets INVENTION 
acquired over the distributed system. These Java applets 

may be stored as Java classes available from various class Overview 

servers in the system. In one aspect, the portions of applet The present invention is directed toward distributed object 
execution code are Java classes. Also, the distributed object 55 systems and will be described with reference to several 
system may include a naming service used by a client to preferred embodiments as illustrated in the accompanying 
locate the applet server for a particular class. drawings. The invention may be practiced within the context 
In one embodiment, an applet server retrieves the of any suitable distributed object system, including those 
requested applet execution code by determining whether a defined under CORBA or any other suitable specification, 
portion of the applet execution code is found within its local 60 However, for purposes of illustration, an embodiment of the 
file set. If the portion is present, then the applet server reads present invention will be described primarily within the 
a file in order retrieve the code and then returns it to the context of an Object Request Broker (ORB) implemented 
requesting client. If the portion is not present in the file set, under the CORBA specification from the Object Manage- 
then the applet server queries the naming service to deter- ment Group (OMG), Revision 2.0, dated July 1995, which 
mine if there is another applet server within the distributed 65 is incorporated herein by reference. FIG. la diagrammati- 
object computing system that is associated with the desired cally illustrates the overall architecture of a representative 
portion. If this second applet server is found, it may perform distributed object system suitable for implementing an 
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embodiment of the present invention. FIG. lb diagrammati- 
cally illustrates some possible flow paths that a request from 
a client to a servant object may follow within such an 
architecture that includes a three-level dispatch mechanism. 
FIG. 1c shows one object reference data structure that may 
be used by a client to refer to a servant object. 

A distributed object system 10 typically includes an 
Object Request Broker (ORB) 11 as is symbolically illus- 
trated in FIG. la. ORB 11 provides all of the location and 
transport mechanisms and facilities necessary to deliver a 
call from a client to a servant (target object) and to return a 
response to the client, as will be discussed below with 
reference to FIG. lb. The client and servant may be located 
in the same process, in different processes on the same 
machine, or on completely different machines. For the 
purposes of this discussion, client 20 may be any code that 
invokes an operation on a distributed object and thus may or 
may not take the form of a distributed object or a process. 
A distributed object may have a wide variety of represen- 
tations. By way of example, the distributed object may be a 
C++ object that has been provided by an application devel- 
oper. Alternatively, an implementation for a distributed 
object may be developed within a visual application builder 
15. This visual application builder allows a developer to 
visually select existing object types from a catalog and 
graphically connect the services provided by one object to 
the services needed by another (attributes, arguments, results 
etc.) in order to create a new implementation for an object. 

An object development facility 16 may be used to sim- 
plify the creation and the installation of distributed objects. 
It is used to "wrap" or encapsulate developer objects in 
distributed object code. As such, object development facility 
16 may be used to transform a developer object into an ORB 
object implementation 14. In this example, ORB object 
implementation 14 is presented as a server as shown by its 
location in the diagram. A developer uses an interface 
definition language to define an interface for an ORB object, 
provides a developer object implementation that implements 
that object's behavior, and then uses the object development 
facility 16 in order to produce an ORB object implementa- 
tion 14. At run time, an instance of this ORB object (a 
servant object) is created that will utilize this ORB object 
implementation 14. It should be appreciated that the object 
development facility may also be used to create objects that 
take the role of clients at some point 

Client 20 communicates with a servant by way of a stub 
21, a subcontract layer 36, possibly a filter 40, and a 
transport layer 38. Stub 21 includes a surrogate 22, a method 
table 24 and stub functions 25. Client 20 communicates 
initially with surrogate 22 that appears to the client as the 
servant object. Alternatively, client 20 may communicate 
directly with the servant object through a dynamic invoca- 
tion interface (DII) 26 instead of through surrogate 22, 
method table 24 and stub functions 25. Dynamic invocation 
interface 26 is used to enable clients to construct dynamic 
requests. One procedure by which a client may make a call 
to a servant utilizing the above layers is described in more 
detail below with reference to FIG. lb. 

Subcontract layer 36 provides the functionality required 
by an object in order to utilize subcontracts to implement 
various services (or features or object mechanisms) named 
by a particular subcontract, as described in greater detail in 
U.S. patent application Ser. No. 08/554,794, filed Nov. 7, 
1995, now U.S. Pat. No. 5,577,251. A subcontract identifies 
a quality of service provided by the distributed object system 
that may be utilized by an individual object. For example, a 
subcontract may identify that the feature of security is to be 
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used for a particular object A technique by which a par- 
ticular subcontract may be associated dynamically at run 
time with a servant object is described in U.S. patent 
application Ser. No. 08/670,682, now U.S. Pat. No. 6,044, 

5 224 filed Jun. 26, 1996. Filter 40, if being used, may perform 
a variety of tasks, such as compression, encryption, tracing, 
or debugging, that are to be applied to communications to 
and from an object 
Transport layer 38 operates to marshal, unmarshal and 

10 physically transport information to and from a servant that 
typically does not share the same process as a client. 
Mechanisms for marshaling and unmarshaling inter-object 
communications are described in U.S. patent application 
Ser. No. 08/673,181, now U.S. Pat. No. 6,032,199 filed Jun. 
26, 1996. A technique for marshaling/unmarshaling an 
object reference is described in U.S. patent application Ser. 
No. 08/670,681, now U.S. Pat. No. 6,044,409 filed Jun. 26, 
1996. 

A standard implementation suite 28 (or object adapter) 

20 represents a set of subcontracts that interact with ORB 
objects 14 in identical ways, as for example object key 
management. One such implementation suite is described in 
U.S. patent application Ser. No. 08/699,782, now U.S. Pat. 
No. 5,991,823 filed Jun. 26, 1996. It should be noted that a 

2g subcontract may belong to multiple implementation suites. 
Also, implementation suites may utilize different subcon- 
tracts. A skeleton, that may take the form of either static 
skeleton 32 or dynamic skeleton 30, is used to transform 
requests into a format required by a servant object 78 (as will 

30 be explained in more detail below with reference to FIG. 
lb). Thus, skeletons 30 and 32 call an appropriate servant 
object 78. Static skeleton 32 is used to call interface-specific 
object implementations 14, while dynamic skeleton 30 is 
used generically when interface-specific objects are not 

35 available. An ORB interface 34 is the interface that goes 
directly to the ORB that is the same for all ORBs and does 
not depend upon an object's interface or object adapter. 

An ORB daemon 46 is responsible for ensuring that 
object servers are active when invoked by clients. A tech- 

4Q nique for starting object servers is disclosed in U.S. patent 
application Ser. No. 08/408,645 filed Mar. 22, 1995, now 
abandoned which is hereby incorporated by reference. 

Secure Protocol 42 is a secure interoperability protocol 
that secures the internet inter-ORB protocol and helps to 

45 transmit information through transport layer 38 in a secure 
fashion. This may mean integrity protection, confidentiality, 
etc. The internet inter-ORB protocol is a protocol that 
typically communicates between processes on different 
machines. However, in some cases, the internet inter-ORB 

50 protocol may communicate between processes on the same 
machine. The security server 54 is a security administration 
server that secures the services that are used between pro- 
cesses on different computers. 

Type code/ Any module 44 implements "Typecode" and 

55 "Any" objects. Typecode describes an Interface Definition 
Language (IDL) data type, allowing type descriptions to be 
transmitted between clients and servers. An instance of an 
IDL data type may be encapsulated by an Any object An 
Any object refers to typecode of the encapsulated data, and 

60 a generic encoding of the data. 

An implementation repository 50 is used to store infor- 
mation relating to object servers. Specifically, implementa- 
tion repository 50 stores the information needed to start a 
server process. For example, implementation repository 50 

65 stores information such as the location of the server 
program, any arguments to the program, and any environ- 
ment variables to pass to the program, etc. 
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Simple persistence 56 uses an Interface Definition Lan- 
guage (IDL)-defined type and the output from running that 
IDL type through the IDL compiler, together with a portion 
of additional code so that an IDL-defined type can be read 
from, and written to, disk. A naming service 52 is used to 5 
name ORB objects. A client may use naming service 52 to 
find a desired object by name. Naming service 52 returns an 
object reference, that in turn may be used to send requests 
to that object. An Interface Repository 48 (IFR) knows about 
all interfaces for all objects within the distributed object 1Q 
system. 

A request made by a client using a method table ("ra- 
table") dispatch will pass through a variety of the aforemen- 
tioned layers of the architecture on its way to the servant as 
diagrammatically illustrated in FIG. lb. The request is 
initiated by a client and may take any suitable form. The 
form of the request will depend to a large extent upon the 
nature of the programming language used to create the 
client. By way of example, if the client is written in the C++ 
language, the request may take the form of a C++ method 
call 62. The call is made to a designated object reference 
taking the form of a surrogate. The surrogate includes 
methods that comply with the object's interface. 

As will be appreciated by those skilled in the art, the 
object reference used at different locations within a distrib- 2S 
uted object system may vary significantly in appearance. In 
the embodiment described, the client side object reference is 
a dual pointer (referred to herein as a "fat pointer' 7 )- A fat 
pointer contains two distinct pointers. A first pointer points 
to a client representation ("client rep") associated with the 3Q 
referenced object. A second pointer points to a method table 
of the method table dispatch 24 that is associated with the 
referenced object. A client representation is an object that 
has methods that support invocation as well as CORBA 
defined "pseudo" object reference operations. These opera- 35 
tions include, but are not limited to, a "duplicate" method, 
a "release" method, a "narrow" method, a "hash" method, 
and an "is equivalent" method. 

After the client has initiated a call, the call is processed 
using a method table dispatch mechanism 24. Such a tech- ^ 
nique is disclosed in U.S. patent application Ser. No. 08/307, 
929 filed Sep. 19, 1994, now abandoned and is hereby 
incorporated by reference. 

The method table dispatch mechanism uses a method 
table that contains a list of pointers to stub functions 25, one 45 
of which is associated with the method to be invoked. Stub 
functions 25 receive a function or procedure call in the 
"native" language of the client process, then use either a 
subcontract layer 36 or a native call to eventually call the 
corresponding servant object. Hie native language may be 50 
any suitable language, as for example a language such as 
C++. 

Method table dispatch 24 determines the appropriate one 
of the stub functions 25 to process the method call, and then 
pairs the method call with the appropriate stub function. In 55 
the event that the client making the method call is in the 
same process as the servant object, a local stub function is 
called. The local stub function sends the method call directly 
to servant object 78. A technique for routing calls within a 
local process is described in U.S. patent application Ser. No. 60 
08/670,684 filed Jun. 26, 1996, now at the Board of Appeal. 
Alternatively, if the servant object is in a different process, 
i.e. a remote process, a remote stub function is called. The 
remote stub function invokes the client representation, that 
delivers the invocation to servant object 78. ss 

Subcontracts implemented by subcontract layer 36 are 
logic modules that provide control of the basic mechanisms 
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of object invocation and argument passing that are important 
in distributed object systems. A subcontract implemented by 
subcontract layer 36 determines a specific quality of service 
for use by an object. A subcontract is uniquely identified by 
a subcontract identifier that is typically embedded in an 
object reference. A quality of service is a set of service 
properties. Among possible service properties that are 
selectable are qualities relating to server activation, security, 
transactions, filterability, and clean shut-down. Subcontracts 
are configured such that certain qualities of service are 
available. With predetermined qualities of service, the over- 
head associated with processing individual service proper- 
ties is reduced. Realistically, only "reasonable" or com- 
monly used combinations of service properties are supported 
with subcontracts. However, subcontracts may be created to 
meet the specific requirements of a given distributed object 
system. 

The identification of an appropriate subcontract in sub- 
contract layer 36 may be thought of as the identification of 
a desired function that is unique to that subcontract. For 
example, a marshal function or an unmarshal function is 
defined for each subcontract. Asubcontract marshal function 
is used by a stub to marshal an object reference so that it may 
be transmitted to another address space, or domain. The 
object reference is typically processed by a transport mecha- 
nism in transport layer 38. 

A transport mechanism such as Tl, T2, etc., that is a part 
of the transport layer 38 is used to marshal and physically 
transport information to and from servant objects. 
Information, i.e. the object reference or the request, is 
converted into protocols appropriate to a given domain. By 
way of example, protocols may include, but are not limited 
to, Ethernet protocols and general inter-ORB protocols 
(GIOPs). In some uncommon cases, protocols may even 
entail the use of electronic mail to transmit instructions to be 
implemented on a server. After information is marshaled, the 
transport mechanism then transports information through 
any combination of an operating system, a device driver, or 
a network, that are all a part of hardware 70 used by the 
client side of a distributed object system. 

While transport mechanisms require a conversion of 
information into a protocol appropriate to a given domain, 
some transport mechanisms do not require the encoding of 
information for different domains. One transport mechanism 
that does not require a conversion of information into a 
protocol appropriate to a domain other than the one on 
information originates is termed a "door". Doors are essen- 
tially gateways between two different processes on the same 
host. The use of doors eliminates the need for a conversion 
of information into a canonical implementation in transport 
layer 38, as there is no need to encode information into a 
protocol that may be used by a different machine by virtue 
of the fact that information is remaining on the same host 
and therefore does not require a change of domain. Hence, 
information may simply be "flattened out," or marshaled 
into a stream that is not encoded for use by a different 
machine, and passed between the two processes on the host. 

Once information is transported through hardware 70 
used by the client side, the information is then transported to 
hardware 70 on the server side of a distributed object 
system. Once information is routed through hardware 70, the 
server side of a distributed object system invokes a transport 
mechanism such as Tl, T2 etc. to receive information on an 
end point that is a part of transport layer 38. In the event that 
an end point is not created by transport layer 38, transport 
layer 38 provides the functionality needed for the end point 
to be created by subcontract layer 36. By way of example, 
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a dedicated end point is typically created by subcontract 
layer 36, while cluster end points, which typically include 
network and TCP/IP end points, are typically created by 
transport layer 38. Regardless of whether end points are 
created by subcontract layer 36 or transport layer 38, end 5 
points "live in," i.e. are a part of, transport layer 38. End 
points are essentially ports that receive information from a 
different domain. After an end point in transport layer 38 
receives information transported from a different domain, 
the end point then dispatches the information from transport 1Q 
layer 38 to subcontract layer 36. Subcontract layer 36 then 
dispatches the information to the skeleton and the servant. 
Such a technique for performing this three-level dispatch is 
described in U.S. patent application Ser. No. 08/670,700 
filed Jun, 26, 1996, still pending. 15 

Subcontract layer 36 provides the functionality to unmar- 
shal at least some of the information it has received. That is, 
subcontract layer 36 unmarshals at least part of the request. 
Then, the request is dispatched to a skeleton 31 that trans- 
forms the request into an implementation specific format 20 
required by servant object 78. The skeleton 31 may either be 
a static skeleton 32 or a dynamic skeleton 30 as described 
above. 

In general, a remote request is routed through the client 
side and the server side as described above. The method call 2 s 
62 is received, method table dispatch layer 24 is used to 
identify an appropriate subcontract prior to the selection of 
a transport mechanism in transport layer 38 that marshals the 
request and prepares it for transport to another domain. 
Through hardware 70, the marshaled request is transported 30 
to the server side where it is received on an end point that 
is a part of transport layer 38. An appropriate end point 
receives information transported across a wire, and infor- 
mation is dispatched from transport layer 38 to subcontract 
layer 36, that provides the functionality to at least partially 35 
unmarshal the information it has received. The subcontract 
layer then dispatches the request to skeleton 31 that trans- 
forms the request into a specific format required by servant 
object 78. This path is shown by arrow 77, and is the path 
that may be taken by both remote and local requests. 40 

However, if a client and a server are in a local process, i.e. 
both the client and the server are in the same process, the use 
of the path shown by arrow 77 as described above is 
unnecessarily complex. If it is known that the client and the 
server are in the same process, it is possible to shorten the 45 
invocation path, or flow path of a request for service. If a 
local process may be identified when an object reference is 
created, shortened flow paths, i.e. the paths represented by 
arrows 75 and 76, may be taken to send a request from a 
client to a server that are on the same host. The path 50 
represented by arrow 76 is more likely to be taken, as it uses 
subcontract layer 36 to identify an appropriate subcontract. 
However, in situations in which an appropriate subcontract 
does not need to be explicitly identified, the path represented 
by arrow 75 may be taken. 55 

FIG. lc will now be used to describe an embodiment of 
an object reference. As will be familiar to those skilled in the 
art, object references may take a variety of forms depending 
upon the location within the process that they are being held 
at any given time. However, by way of background, a 60 
representative object reference for use in a system that 
utilizes a low overhead implementation suite is illustrated in 
FIG. lc. In the implementation shown therein, object refer- 
ence 150 includes a host identifier 152, a port designation 
154, and an object key 156. Object key 156 includes a 65 
subcontract identifier 158, a server identifier 160, an imple- 
mentation identifier 162, and a user key 164. Host identifier 
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152 denotes a particular computer in a network, while port 
designation 154 identifies the port of the selected computer 
that is to be used for communication. Object key 156 
provides further identifying information used in order to 
locate a desired servant object on its host machine. 

Server identifier 160 names a particular process or pro- 
gram in which the servant object resides, while user key 164 
is a unique number or string used to locate the servant within 
the process named by server identifier 160. Subcontract 
identifier 158 is used to attach the protocol of a particular 
subcontract and its associated services with a servant, and 
implementation identifier 162 names an implementation of 
an interface that is to be used with that servant object. 

Finding and Downloading Java-Based Applications 

An embodiment of the present invention provides a 
mechanism by which a requesting client may acquire the 
classes it needs within a distributed object system in order to 
run a particular applet. In one embodiment, this mechanism 
uses an object request broker (ORB) in order to communi- 
cate with one or more class servers that provide access to the 
class files needed. Thus, an ORB of a distributed object 
system is used to find the class files needed in a location 
independent manner. One advantage to using an ORB is that 
these class files and their associated class server may be 
located anywhere within the distributed object system yet 
may still be found by the client. Also, this mechanism allows 
a client a single point of access to the distributed object 
system in order to find the class files that it needs. And even 
though these class files may be in different locations, these 
class files are retrieved in a manner transparent to the 
requesting client. That is, the client knows a base class that 
it wishes to load, but is mercifully unaware of all the 
machinations behind the scenes required to find other classes 
used or needed by this base class. Also, a request from a 
client may pass from an ORB of one distributed object 
system to an ORB of another, 

A wide variety of clients are contemplated that may 
benefit from being able to find and download executable 
code according to the present invention. By way of example, 
one particular client is a client running Java software that is 
enabled to communicate with an ORB and to download Java 
classes. Also, in a broad sense, an embodiment of the present 
invention is able to load any applet execution code. That is, 
applet execution code may be any execution code that can be 
downloaded and executed by a client. As used herein, the 
term "applet" refers to a body of executable program code, 
which code is effective to implement a function or facility 
when used in conjunction with a supporting execution 
environment. An "applet" may refer to a wide variety of 
types of execution code. By way of example, an applet may 
be a collection of byte codes representing classes that are 
executed by a remote interpreter, such as Java classes that 
are executed using a Java language interpreter. These byte 
codes may also be compiled before execution, or may even 
undergo a combination of interpretation/compilation before 
execution. The Java interpreter may reside inside a Web 
browser. And in particular, applet execution code may refer 
to code that represents an implementation of a Java class. 
And applet may mean in particular a small Java program that 
can be embedded in another application such as an HTML 
document in order to provide interactive, executable content 
on a Web page. A Java class may be defined as a collection 
of data and methods that operate on that data. Together, the 
data and methods describe the state and behavior of an 
object. 

The present invention is useful and advantageous in many 
different scenarios. By way of example, an embodiment of 


12/16/2002, EAST Version: 1.03.0007 


US 6,2i 

11 

the present invention is useful when a Java client wishes to 
query an object about what its presentation is. The presen- 
tation of a particular object may be used to run an executable 
program in a small window within a larger window. An 
object may be given the ability to give to the client its 
presentation, that is an implementation of the object's "front 
end" or interface. In this example, the presentation of an 
object is an applet that is represented as a location indepen- 
dent object. Thus, by way of an embodiment of the present 
invention, the Java client may use the ORB in order to find 
this location independent object wherever it may be within 
the distributed object system. Once found, the applet may be 
downloaded to the client by way of an embodiment of the 
present invention and executed within the client. The present 
invention may be applicable in many other situations that 
will be apparent from the description of the figures below. 
FIGS. 2 and 3 illustrate an embodiment of the present 
invention for use within a distributed object system, and 
FIGS. 4 and 5 show a flow chart for how the invention may 
be practiced according to one embodiment. 

FIG. 2 illustrates graphically how in one embodiment of 
the invention a Java client 202 may communicate via a 
communication mechanism 206 in order to acquire Java 
class files 209 and 211 within a distributed object system 
200. Java client 202 may be a Web browser incorporating a 
Java interpreter or may be any Java-enabled client that 
wishes to download an applet for use. A communication 
mechanism for allowing a Java client to communicate with 
remote class servers in order to find and download class files 
may be implemented in a wide variety of manners. By way 
of example, this communication mechanism may be imple- 
mented as an object request broker of a distributed object 
system. And in particular, this object request broker, or 
ORB, may be implemented as described above with refer- 
ence to FIGS. la 9 lb, and 1c. Class servers A and B are 
objects within the distributed object system that are imple- 
mentations of a particular interface definition language 
(IDL). In other words, a class server may be defined by an 
IDL and may include a variety of operations and attributes 
defined upon it. Associated with each class server on the 
same machine are files containing Java classes. For example, 
class server A has an associated file set 209 and class server 
B has an associated file set 211. Thus, Java classes may be 
located on any machine within a distributed object system 
and are accessible by a Java client via their associated class 
server as will be explained in more detail below. 

Also included within the distributed object system 200 is 
a naming service 208. The naming service 208 allows object 
names to be registered so that a client may determine the 
location of a particular object by reference to the naming 
service. In this way, objects may refer to other objects by 
name. A naming service may be implemented in a wide 
variety of manners. By way of example, the naming service 
may be one module of the Object Services layer of a 
distributed object system as defined under the OMG 
CORBA standard. 

In one embodiment, the process by which a Java client 
acquires classes for an applet occurs as follows with refer- 
ence to the circled numerals. Arrows (1) show how a Java 
client 202 may use the naming service 208 and the ORB 206 
in order to determine a particular class server A that has 
access to a given class name that the client desires to be 
loaded. If this class name is contained within the file set 209 
associated with class server A, then arrow (2) shows how 
class server A retrieves the file containing the class name 
from its file set 209. However, if this class name is not 
present in the associated file set 209, then arrows (3) 
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illustrate graphically how class server Awill itself utilize the 
naming service in order to determine a second class server 
B that does have access to the desired class name. Arrow (4) 
shows how this class server B will access its associated file 

5 set 211 in order to retrieve the executable program code 
corresponding to this class name. Arrow (5) shows how this 
class code corresponding to the class name desired by the 
Java client is finally returned via the ORB 206 to the Java 
client 202. It should be appreciated that the communication 

1(J taking place as indicated by arrows (1), (3) and (5) is 
machine independent. That is, the code associated with a 
particular class name may be moved to a new machine or 
given a new name as long as the naming service is updated 
to indicate the new location or name. In this fashion, an 
embodiment of the present invention advantageously allows 

15 classes associated with an applet to be located anywhere 
within a distributed object system in a way that is transparent 
to the requesting client. 

FIG. 3 shows in greater detail the Java client 202 and its 
implementation that allows it to communicate with the ORB 

20 and to download Java classes. Java client 202 may be a Web 
browser using a Java interpreter or any Java-enabled client. 
Simply by itself Java client 202 with only a Java interpreter 
is not enabled to talk to a distributed object system through 
the use of an ORB 206. Thus, an ORB binding mechanism 

25 302 is used to enable the Java client to communicate with a 
distributed object system through an ORB 206. In one 
embodiment, ORB binding 302 is a collection of Java 
classes that the Java client acquires in a conventional way 
such as through a URL address or through a local file 

30 system. The ORB binding 302 is a module loaded in to a 
Java interpreter that enables the Java client to talk to an 
interface definition language (IDL) and to make distributed 
object calls. In one sense, ORB binding 302 is a connector 
between a Java interpreter and an interface definition lan- 

35 guage. The Java client bootstraps itself to the ORB by 
loading in these classes and thus extending it capabilities. 
The ORB binding may be implemented in a variety of 
manners. By way of example, ORB binding 302 may be a 
software module that is described in pending U.S. patent 

40 applications with Ser. No. 08/534,966 filed Sep. 28, 1995, 
now U.S. Pat. No. 5,737,607, Ser. No. 08/539,999 filed Oct. 
6, 1995, now U.S. Pat. No. 5,758,186, Ser. No. 08/540,129 
filed Oct. 6, 1995, now U.S. Pat. No. 5,815,708, and Ser. No. 
60/004,057 filed Sep. 20, 1995, which all are hereby incor- 

45 porated by reference. 

Once the Java client 202 has the capability to talk to an 
ORB 206 it also needs the capability to load and resolve 
classes available from the distributed object system. The 
network class loader 304 is a mechanism that allows a Java 

50 client to load and define new classes at run time. It also has 
functionality to allow classes to be resolved. If a down- 
loaded class uses other classes that are not currently known 
or defined within the Java client, these other classes must be 
found and loaded ("resolved"). The network class loader 304 

55 is called to acquire these needed classes. The network class 
loader also emits requests from the Java client in response to 
a client request for particular Java code. The network class 
loader is available within a computer network, and may be 
loaded or acquired by the Java client in a conventional way 

60 that a Java client acquires a class. For example, a call to a 
local file system or to a known URL address loads the 
network class loader 304. The network class loader 304 may 
be loaded into Java client 202 as shown by arrow 306 where 
it is then shown within the Java client as 304'. Once the ORB 

65 binding 302 and the network class loader 304' are present in 
Java client 202, the Java client is ready to acquire needed 
Java classes over a distributed object system. 
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FIG. 4 shows a flow chart 400 for acquiring a Java class reference to an original class name, the client application is 

needed by a particular client according to one embodiment able to load and resolve all necessary classes for this original 

of the present invention. For example, in the course of a class over a distributed object network, 

particular client application, a distributed object has pro- FIG. 5 explains in greater detail step 408 of FIG. 4 

duced the name of a class needed to execute within a Java 5 according to one embodiment. Because a class server may 

interpreter. The procedure shown in FIG. 4 uses a distributed not be able to find a particular class within its own associated 

object system according to one embodiment of the present file set, it may be necessary to look elsewhere within the 

invention in order to load this class and any other classes it distributed object system for the class needed. In this 

uses. A wide variety of classes exist that may be desirable for fashion, an embodiment of the present invention is able to 

loading into a client application. A class desired may depend 1Q find Java classes anywhere within a distributed object sys- 

upon the specific client application. By way of example, tem and in a manner transparent to the client. In this 

classes that implement a portion of a graphical user embodiment, the original class server found determines that 

interface, so-called "panel classes", are suitable for acquir- it does not have local access to the class needed and is able 

ing through use of an embodiment of the present invention. to search for other class servers. 

These "panel classes" are especially suitable when the 5 Initially, in step 502, the class server determines whether 

graphical user interface may vary based upon the nature of the desired class is present in the file set of the class server, 

a distributed object that it is being used to manipulate. If the class (and its corresponding execution code) is found 

When this acquire class procedure begins, the ORB in the server's file set, then in step 504 this file is read and 

binding and network class loader have already been loaded the appropriate execution code is passed back to the NCL 

into the Java client as shown in FIG. 3. In a first step 402, 2 o within tne ^ ava client. However, if the class is not in the 

the class name that is desired to be loaded is received. Next, server's file set then this class server must look elsewhere in 

the class server object located somewhere within the dis- order to find the class. In step 506 this first class server 

tributed object system that has access to the desired class queries the naming service in order to find a class server that 

name must be determined. Thus, in step 403, the network does correspond to the desired class name. In other words, 

class loader (NCL) queries the naming service in order to 2S the first class server is looking for another class server that 

determine the appropriate class server. This step is illustrated has an associated file set that includes a file with the class 

graphically in FIG. 2 by arrows (1). In step 404, if no class name that is desired. Step 508 tests whether such a class 

server is found that corresponds to the desired class name, server has been found. If not, then step 510 returns an 

an error is returned in step 405 and then the procedure ends. appropriate error message and the procedure ends. However, 

However, if a class server is found that corresponds to the 30 if an appropriate class server is found, then in step 512 the 

desired class name, then in step 406 the ORB establishes a execution code corresponding to the class name is requested 

connection to this found class server. from the found class server. 

Now that the class server has been found, the NCL It should be appreciated that step 512 may be a recursive 

requests the class execution code from the class server that step. That is, when the execution code is requested from the 

corresponds to the desired class name in step 408. The 35 found class server, it may be that this found class server does 

execution for a particular class may be represented in a wide not have access to the class but may need to call the naming 

variety of manners. By way of example, this execution code service itself in order to find an appropriate class server. This 

may take the form of an array of bytes that are stored in a situation may occur if a class is moved from one class server 

file or files. In step 408 the class server may obtain the to another. Once the execution code has been found and read 

necessary class files locally or it may need to request these 40 from the appropriate file, then in step 514 the resulting bytes 

files of another class server. This process will be described are passed back to the NCL within the Java client. After this 

in greater below with reference to FIG. 5. step the procedure ends. 

Once this execution code for class name has been The present invention as described above employs various 

retrieved, it is delivered to the network class loader within process steps involving data stored in computer systems, 

the Java client in step 410. Next, instep 412, the NCL passes 45 These steps are those requiring physical manipulation of 

this execution code to the Java interpreter. At this point, physical quantities. Usually, though not necessarily, these 

because the recently loaded class may use other classes, the quantities take the form of electrical or magnetic signals 

Java interpreter must resolve any undefined class references. capable of being stored, transferred, combined, compared, 

For example, if the retrieved execution code of the class and otherwise manipulated. It is sometimes convenient, 

indicates that other classes are used and these classes are not 50 principally for reasons of common usage, to refer to these 

currently defined within the Java interpreter, then the execu- signals as bits, values, elements, variables, characters, data 

tion code for these undefined class names must also be structures, or the like. It should be remembered, however, 

retrieved from class servers somewhere within the distrib- that all of these and similar terms are to be associated with 

uted object system. Step 416 tests whether there are any the appropriate physical quantities and are merely conve- 

unrcsolved classes remaining within the Java interpreter. If 55 nient labels applied to these quantities, 

not, this indicates that all execution code needed by the Further, the mampulations performed are often referred to 

original class requested is present in the Java interpreter, and in terms such as identifying, running, or comparing. In any 

in step 420 this original class is returned to the requesting 0 f the operations described herein that form part of the 

client as being resolved. present invention these operations are machine operations. 

However, if there are one or more unresolved classes, then 60 Useful machines for performing the operations of the 

in step 418 the Java interpreter asks the NCL for the present invention include general purpose digital computers 

execution code of a first unresolved class. From step 418 the or other similar devices. In all cases, there should be borne 

procedure loops back to step 408 in which the NCL requests in mind the distinction between the method of operations in 

from the class server the appropriate class execution code. In operating a computer and the method of computation itself, 

this fashion, this portion of FIG. 4 may loop through steps 65 The present invention relates to method steps for operating 

408 to 418 until all execution code has been retrieved for all a computer in processing electrical or other physical signals 

unresolved classes. Thus, it should be appreciated that by to generate other desired physical signals. 


12/16/2002, EAST Version: 1.03.0007 


US 6,260,078 Bl 

15 16 

The present invention also relates to an apparatus for above-described method steps. The above -described devices 

performing these operations. This apparatus may be spe- and materials will be familiar to those of skill in the 

daily constructed for the required purposes, or it may be a computer hardware and software arts, 

general purpose computer selectively activated or reconfig- Although the foregoing invention has been described in 

ured by a computer program stored in the computer. The 5 some detail for purposes of clarity of understanding, it will 

processes presented herein are not inherently related to any be apparent that certain changes and modifications may be 

particular computer or other apparatus. In particular, various practiced within the scope of the appended claims. For 

general purpose machines may be used with programs instance, the communication mechanism used between the 

written in accordance with the teachings herein, or it may be client and class server may be any suitable object request 

more convenient to construct a more specialized apparatus 10 broker. Also, the naming service may be any module capable 

to perform the required method steps. The required structure of identifying the location of a class name within a distrib- 

for a variety of these machines will appear from the descrip- uted object system. And the naming service may be part of 

tion given above. an object request broker, or may be a separate module. In 

In addition, the present invention further relates to com- addition, although the classes have been described as being 

puter readable media that include program instructions for 15 stored on com P uter ,he y ™y be present within a 

performing various computer-implemented operations. The com P uter s y stem on ^ computer-readable media. And the 

media and program instructions may be those specially P reseDt » ca P able ° f lo "dmg any appropriate 

designed and constructed for the purposes of the present P ortlon ° A f ««ulAle code, and not necessarily in units of 

invention, or they may be of the kind well known and classes : And although the above examples describe applet 

available to those having skill in the computer software arts, ^execution code as being in one form programs for the Java 

Examples of computer-readable media include, but are not programming environment, it wdl be appreciated by those of 

limited to, magnetic media such as hard disks, floppy disks, staU m } b f 1 art .* at the term applet execution code refers to 

and magnetic tape; optical media such as CD-ROM disks; an y suUable "rf°™ation that may be downloaded in a 

magneto-optical media such as floptical disks; and hardware ™nner ^sparent t 0 a c hent and men executed by that 

devices that are specially configured to store and perform 2 ^ h ^ U Also although the ORB binding and network class 

program instructions, such as read-only memory devices loader ^ve been described as two separate modules, it is 

(ROM) and random access memory (RAM). Examples of contemplated that they may form one unit that has the 

program instructions include both machine code, such as f«n<*onahty to d OW , * Java , chent t°«>°™cate with an 

produced by a compiler, and files containing higher level 0R ? and to J f a classes. Therefore, the described 

code that may be executed by the computer using an ' embodiments should be taken as illustrative and not 

int t restrictive, and the invention should not be limited to the 

nr . , t . , , 4 j details given herein but should be defined by the following 

FIG. 6 illustrates a typical computer system in accordance . . & . A , . , „ - . t ^ 7 & 

... . • ** ttT * * inn claims and their full scope of equivalents, 

with the present invention. The computer system 100 ^ claim- 

includes any number of processors 102 (also referred to as * A r . . . . 

4 , J ™, rT , 4l V . . 4 *~ 1. A computer apparatus for use tn acquiring applet 

central processing units, or CPUs) that are coupled to 35 4 . T .,.. rr . * ^ ^ * *■ : 

j - 1 j- : 1A , /4 . „ , execution code within a distributed object computing system 

storage devices including primary storage 106 (typically a . . ,. 4 , , , r, * * 

j nA»#\ ■ * -1 having clients and applet servers, said computer apparatus 

random access memory, or RAM), primary storage 104 6 . . vv 7 v 

(typically a read only memory, or ROM). As is well known comprising. 

in the art, primary storage 104 acts to transfer data and a P rocessm 8 umt > 

instructions uni-directionaUy to the CPU and primary stor- 40* — an input/output device coupled to said processing unit; 

age 106 is used typically to transfer data and instructions in a storage device in communication with said processing 

a bi-directional manner. Both of these primary storage unit; 

devices may include any suitable of the computer- re ad able an object request broker arranged to facilitate communi- 

media described above. A mass storage device 108 is also cation between said clients and said applet servers, said 

coupled bi-directionally to CPU 102 and provides additional 4s object request broker being further arranged to receive 

data storage capacity and may include any of the computer- a request for applet execution code from a client 

readable media described above. The mass storage device enabled to receive said applet execution code; 

108 may be used to store programs, data and the like and is a first applet server being arranged to retrieve said applet 

typically a secondary storage medium such as a hard disk execution code in response to said request from said 

that is slower than primary storage. It will be appreciated 50 client and to return said applet execution code to said 

that the information retained within the mass storage device client; and 

108, may, in appropriate cases, be incorporated in standard a Java client with ORB binding software and network 

fashion as part of primary storage 106 as virtual memory. A class loader software operating to allow said client to 

specific mass storage device such as a CD-ROM 114 may acquire said applet execution code without requiring 

also pass data uni-directionally to the CPU. 5s said client to know the location of said applet execution 

CPU 102 is also coupled to an interface 110 that includes code within said distribution object computing system, 

one or more input/output devices such as such as video 2. A computer apparatus as recited in claim 1 wherein said 

monitors, track balls, mice, keyboards, microphones, touch- object request broker is associated with a naming service 

sensitive displays, transducer card readers, magnetic or arranged to receive a request from said client to identify said 

paper tape readers, tablets, styluses, voice or handwriting 60 first applet server associated with said applet execution 

recognizers, or other well-known input devices such as, of code. 

course, other computers. Finally, CPU 102 optionally may 3. A computer apparatus as recited in claim 2 wherein said 

be coupled to a computer or telecommunications network first applet server is arranged to query said naming service 

using a network connection as shown generally at 112. With to determine a second applet server to retrieve said applet 

such a network connection, it is contemplated that the CPU 65 execution code. 

might receive information from the network, or might output 4. A computer apparatus as recited in claim 3 further 

information to the network in the course of performing the comprising: 
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a mass storage unit in communication with said central 
processing unit, said mass storage unit including files 
containing said applet execution code, wherein said 
first applet server is further arranged to retrieve said 
applet execution code from said files. 

5. In a distributed object computing system having clients, 
applet servers and an object request broker arranged to 
facilitate communication between said clients and said 
applet servers, a computer-implemented method of acquir- 
ing applet execution code within said distributed object 
computing system, comprising: 

loading ORB binding software into a client to enable said 
client to pass requests for said applet execution code to 
said object request broker, wherein said applet execu- 
tion code can be located anywhere within said distrib- 
uted object computing system; 

loading network class loader software into said client to 
enable said client to load and resolve portions of said 
applet execution code that are returned to said client 
from one of said applet servers, wherein execution code 
needed to resolve said portions of said applet execution 
code that are returned to said client can be located 
anywhere within said distributed object computing 
system; 

querying said object request broker by said client to 
determine a first applet server to obtain said applet 
execution code; 

requesting a portion of said applet execution code from 
said determined first applet server with said object 
request broker, 

retrieving at least said portion of said applet execution 
code with said first applet server; and 

returning said portion of said applet execution code 
retrieved by said first applet server to said client with 
said object request broker, thereby allowing said client 
to acquire said applet execution code without requiring 
said client to know the location of said applet execution 
code within said distribution object computing system. 

6. A method as recited in claim 5 wherein querying said 
object request broker includes querying a naming service of 
said distributed object computing system. 

7. A method as recited in claim 6 wherein retrieving said 
portion of said applet execution code includes: 

determining whether said portion of said applet execution 
code is within a file set associated with said first applet 
server; 

reading a first file to retrieve said portion of said applet 
execution code when it is determined that said portion 
of said applet execution code is within a file set of said 
first applet server; and 

querying said naming service with said first applet server 
to determine a second applet server within said distrib- 
uted object computing system that is associated with 
said portion of said applet execution code when it is 
determined that said portion of said applet execution 
code is not within a file set of said first applet server. 

8. A method as recited in claim 7 wherein returning said 
portion of said applet execution code is performed by said 
second applet server first returning said portion of said 
applet execution code to said first applet server. 

9. A method as recited in claim 7 wherein returning said 
portion of said applet execution code is performed by said 
second applet server returning said portion of said applet 
execution code directly to said client 

10. A method as recited in claim 7 wherein said portion of 
said applet execution code corresponds to a Java class. 
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11. A method as recited in claim 5 further comprising: 
determining whether said portion of said applet execution 

code returned to said client by said applet server 
contains any unresolved references to said applet 
execution code; and 
requesting additional applet execution code correspond- 
ing to said unresolved reference from said first applet 
server through said object request broker when it is 
determined that said portion of said applet execution 
code contains an unresolved reference. 

12. In a distributed object computing system having 
clients, applet servers and an object request broker arranged 
to facilitate communication between said clients and said 
applet servers, a computer-implemented method of acquir- 
ing applet execution code within said distributed object 
computing system comprising: 

loading ORB binding software into a client to enable said 
client to pass requests for said applet execution code to 
said object request broker, wherein said applet execu- 
tion code can be located anywhere within said distrib- 
uted object computing system; 

loading network class loader software into said client to 
enable said client to load and resolve portions of said 
applet execution code that are returned to said client 
from one of said applet servers, wherein execution code 
needed to resolve said portions of said applet execution 
code that are returned to said client can be located 
anywhere within said distributed object computing 
system; 

querying a naming service of said distributed object 
computing system by said client to determine a first 
applet server to obtain said applet execution code; 

requesting a portion of said applet execution code from 
said determined first applet server with said object 
request broker; 

retrieving at least said portion of said applet execution 
code with said first applet server; and 

returning said portion of said applet execution code 
retrieved by said first applet server to said client with 
said object request broker, thereby allowing said client 
to acquire said applet execution code without requiring 
said client to know the location of said applet execution 
code within said distribution object computing system. 

13. A method as recited in claim 12 wherein retrieving 
said portion of said applet execution code includes: 

determining whether said portion of said applet execution 
code is within a file set associated with said first applet 
server, 

reading a first file to retrieve said portion of said applet 
execution code when it is determined that said portion 
of said applet execution code is within a file set of said 
first applet server; and 

querying said naming service with said first applet server 
to determine a second applet server within said distrib- 
uted object computing system that is associated with 
said portion of said applet execution code when it is 
determined that said portion of said applet execution 
code is not within a file set of said first applet server. 

14. A method as recited in claim 13 wherein returning said 
portion of said applet execution code is performed by said 
second applet server first returning said portion of said 
applet execution code to said first applet server. 

15. A method as recited in claim 13 wherein returning said 
portion of said applet execution code is performed by said 
second applet server returning said portion of said applet 
execution code directly to said client. 
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16. A method as recited in claim 13 wherein said portion 
of said applet execution code corresponds to a Java class. 

17. In a distributed object computing system having 
clients, applet servers and an object request broker arranged 
to facilitate communication between said clients and said 
applet servers, a computer-implemented method of acquir- 
ing applet execution code within said distributed object 
computing system comprising: 

querying said object request broker by a client using an 
ORB binding mechanism to determine a first applet 
server to obtain said applet execution code, wherein 
said applet execution code can be located anywhere 
within said distributed object computing system; 

requesting a portion of said applet execution code from 
said determined first applet server with said object 
request broker, 

retrieving at least said portion of said applet execution 
code with said first applet server; and 

returning said portion of said applet execution code 
retrieved by said first applet server to said client with 
said object request broker; 

determining whether said portion of said applet execution 
code returned to said client by said applet server 
contains any unresolved references to said applet 
execution code; 

requesting additional applet execution code correspond- 
ing to said unresolved reference from said first applet 
server through said object request broker when it is 
determined that said portion of said applet execution 
code corresponding to said unresolved reference con- 
tains an unresolved reference, said client resolving said 
unresolved reference by using a network class loader 
mechanism, said additional applet execution code cor- 
responding to said unresolved reference can be located 
anywhere within said distributed object computing 
system; and 

wherein said client can acquire said applet execution code 
without said client having to know the location of said 
applet execution code within said distribution object 
computing system. 

18. A computer program product comprising a computer- 
usable medium having computer-readable program code 
embodied thereon for acquiring applet execution code 
within a distributed object computing system, the distributed 
object computing system having clients, applet servers and 
an object request broker arranged to facilitate communica- 
tion between said clients and said applet servers, the com- 
puter program product comprising computer-readable pro- 
gram code for effecting the following within the computer 
system: 

loading ORB binding software into a client to enable said 
client to pass requests for said applet execution code to 
said object request broker, wherein said applet execu- 
tion code can be located anywhere within said distrib- 
uted object computing system; 

loading network class loader software into said client to 
enable said client to load and resolve portions of said 
applet execution code that are returned to said client 
from one of said applet servers, wherein execution code 
needed to resolve said portions of said applet execution 
code that are returned to said client can be located 
anywhere within said distributed object computing 
system; 

querying said object request broker by said client to 
determine a first applet server to obtain said applet 
execution code; 
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requesting a portion of said applet execution code from 
said determined first applet server with said object 
request broker; 

retrieving at least said portion of said applet execution 
5 code with said first applet server; and 

returning said portion of said applet execution code 
retrieved by said first applet server to said client with 
said object request broker, thereby allowing said client 
to acquire said applet execution code without requiring 
10 said client to know the location of said applet execution 
code within said distribution object computing system. 

19. A computer program product as recited in claim 18 
wherein querying said object request broker includes que- 
rying a naming service of said distributed object computing 

15 system. 

20. A computer program product as recited in claim 19 
wherein retrieving said portion of said applet execution code 
includes program code for: 

determining whether said portion of said applet execution 
20 code is within a file set associated with said first applet 
server; 

reading a first file to retrieve said portion of said applet 
execution code when it is determined that said portion 

25 of said applet execution code is within a file set of said 
first applet server; and 
querying said naming service with said first applet server 
to determine a second applet server within said distrib- 
uted object computing system that is associated with 

30 said portion of said applet execution code when it is 
determined that said portion of said applet execution 
code is not within a file set of said first applet server. 

21. A computer program product as recited in claim 20 
wherein returning said portion of said applet execution code 

35 is performed by said second applet server first returning said 
portion of said applet execution code to said first applet 
server. 

22. A computer program product as recited in claim 20 
wherein returning said portion of said applet execution code 

4Q is performed by said second applet server returning said 
portion of said applet execution code directly to said client. 

23. A computer program product as recited in claim 20 
wherein said portion of said applet execution code corre- 
sponds to a Java class. 

45 24. A computer program product as recited in claim 18 
further comprising program code for effecting the following: 
determining whether said portion of said applet execution 
code returned to said client by said applet server 
contains any unresolved references to said applet 
50 execution code; and 

requesting additional applet execution code correspond- 
ing to said unresolved reference from said first applet 
server through said object request broker when it is 
determined that said portion of said applet execution 
55 code contains an unresolved reference. 

25. A computer program product comprising a computer- 
usable medium having computer-readable program code 
embodied thereon for acquiring applet execution code 
within a distributed object computing system, the distributed 
60 object computing system having clients, applet servers and 
an object request broker arranged to facilitate communica- 
tion between said clients and said applet servers, the com- 
puter program product comprising computer-readable pro- 
gram code for effecting the following within the computer 
65 system: 

loading ORB binding software into a client to enable said 
client to pass requests for said applet execution code to 
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said object request broker, wherein said applet execu- 
tion code can be located anywhere within said distrib- 
uted object computing system; 
loading network class loader software into said client to 
enable said client to load and resolve portions of said 5 
applet execution code that are returned to said client 
from one of said applet servers, wherein execution code 
needed to resolve said portions of said applet execution 
code that are returned to said client can be located 
anywhere within said distributed object computing 10 
system; 

querying a naming service of said distributed object 
computing system by said client to determine a first 
applet server to obtain said applet execution code; 

requesting a portion of said applet execution code from 
said determined first applet server with said object 
request broker; 

retrieving at least said portion of said applet execution 
code with said first applet server; and 2 o 

returning said portion of said applet execution code 
retrieved by said first applet server to said client with 
said object request broker, thereby allowing said client 
to acquire said applet execution code without requiring 
said client to know the location of said applet execution 25 
code within said distribution object computing system. 

26. A computer program product as recited in claim 25 
wherein retrieving said portion of said applet execution code 
includes program code for: 

determining whether said portion of said applet execution 30 
code is within a file set associated with said first applet 
server, 

reading a first file to retrieve said portion of said applet 
execution code when it is determined that said portion 
of said applet execution code is within a file set of said 
first applet server; and 

querying said naming service with said first applet server 
to determine a second applet server within said distrib- 
uted object computing system that is associated with ^ 
said portion of said applet execution code when it is 
determined that said portion of said applet execution 
code is not within a file set of said first applet server. 

27. A computer program product as recited in claim 26 
wherein returning said portion of said applet execution code 45 
is performed by said second applet server first returning said 
portion of said applet execution code to said first applet 
server. 

28. A computer program product as recited in claim 26 
wherein returning said portion of said applet execution code 
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is performed by said second applet server returning said 
portion of said applet execution code directly to said client. 

29. A computer program product as recited in claim 26 
wherein said portion of said applet execution code corre- 
sponds to a Java class. 

30. A computer program product comprising a computer- 
usable medium having computer-readable program code 
embodied thereon for acquiring applet execution code 
within a distributed object computing system, the distributed 
object computing system having clients, applet servers and 
an object request broker arranged to facilitate communica- 
tion between said clients and said applet servers, the com- 
puter program product comprising computer-readable pro- 
gram code for effecting the following within the computer 
system: 

querying said object request broker by a client using ORB 
binding software to determine a first applet server to 
obtain said applet execution code, wherein said applet 
execution code can be located anywhere within said 
distributed object computing system; 

requesting a portion of said applet execution code from 
said determined first applet server with said object 
request broker; 

retrieving at least said portion of said applet execution 
code with said first applet server; and 

returning said portion of said applet execution code 
retrieved by said first applet server to said client with 
said object request broker; 

determining whether said portion of said applet execution 
code returned to said client by said applet server 
contains any unresolved references to said applet 
execution code; 

requesting additional applet execution code correspond- 
ing to said unresolved reference from said first applet 
server through said object request broker when it is 
determined that said portion of said applet execution 
code contains an unresolved reference, said client 
resolving said unresolved reference by using network 
class loader software, wherein additional applet execu- 
tion code corresponding to said unresolved reference to 
said client can be located anywhere within said distrib- 
uted object computing system; and 

wherein said client can acquire said applet execution code 
without requiring said client to know the location of 
said applet execution code within said distribution 
object computing system. 
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